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REMARKS 

Claims 1-15 are pending in this application, stand finally rejected, and are at issue herein. 
Reconsideration of claims 1-15 and indication of their allowability at an early date in view of the 
following remarks are respectfully solicited. 

The applicant wishes to thank the Examiner for reconsideration of claim 1 1 and removal 
of the obj ection thereto . 

The Examiner has rejected claims 1-7 under 35 U.S.C. § 102(e) as being anticipated by 
U.S. Patent 6,259,447 to Kanetake et al. The applicant has once again thoroughly considered 
this reference, as well as the Examiner's responses to the applicant's arguments set forth in the 
previous response. However, the applicant must persist in the traversal of this ground of 
rejection. Reconsideration of this ground of rejection and indication of the allowability of claims 
1 -7 in view of the following remarks are respectfully solicited. 

As described in the originally filed application, the text based setup data file is used by 
the suite integration toolkit during the installation process of a suite of applications to be 
installed on a user's machine. While this text based setup data file includes multiple sections, of 
particular interest to the claims of the present application, this data file includes a section that 
contains the listing of all user interface screens to be displayed during the installation process of 
the application suite. Providing a significant advantage to the developers of the application 
suites, this text based listing of the screens to be displayed provides the order in which the 
screens will be utilized by the suite installation toolkit for display to the users during various 
stages of the installation process. This feature is described in the independent claims of this 
application as follows: 

L ... providing a text based setup data file having at least one section 
containing a display order textual listing of the Ul screens . . . 

P. . . . a text based setup database file, said setup database file including a 
display order textual listing identifying specific user interface (Ul) screens to be 
displayed during installation of said components. 
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12. . . . acquiring a textual listing of user interface screens for each of a 
plurality of applications in a suite that are to be installed . . . 

Through such a section in the text based setup data file, the developer of the application 
suite may simply utilize a text editor to rearrange or edit the order of the screens listed in the 
textual listing to modify the order in which the screens are displayed to users during the 
installation process. That is, once the developer has finally edited the listing of the display order 
of the user interface screens, later installation of this suite by an end user will result in the 
various user interface screens being displayed automatically in the order contained in this section 
of the setup data file. The developer need not change where these screens are stored in memory, 
nor their address to effect a reordering. This feature is described in the independent claims of the 
instant application as follows: 

1. 

providing a text editor; and 

editing the display order textual listing of the UI screens in the setup data 
file using the text editor. 

12. 

acquiring the user interface screens identified by the textual listing; and 
displaying the user interface screens identified by the textual listing for 
each of the applications in the suite that are to be installed. 

While the provision of the dedicated section in the text based setup data file that contains 
the display order textual listing of the UI screens allows a developer to modify the order in which 
these screens are displayed during the later installation of this suite, it is important to note that 
this textual listing, and the editing thereof, in no way affects the content or data displayed by 
these screens during the installation process. That is, only the order in which the screens will be 
displayed automatically during the installation of this suite by an end user is affected by the 
editing of this textual listing in the setup data file. The actual content of the screens themselves 
is selected and generated through a different mechanism not of interest to the claims of this 
application. Specifically, the claims of the present application are concerned only with the 
provision of the text based setup data file having a section that contains the display order listing 
of the UI screens in textual format such that the editing or reordering of these screens may be 
accomplished through simply editing this listing via a text editor. 
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With this context in mind, we turn to the Kanetake et al. '447 reference and the 
application thereof as set forth by the Examiner. While the display order textual listing of the 
setup data file of claim 1 provides the automatic ordering of the normal installation process, the 
system of Kanetake et al. '447 is concerned with providing "an automatic execution program that 
is capable of handling an exceptional processing procedure by of a client without changing a host 
application." Kanetake et al. '447, column 1, lines 59-62. As described, these "exceptional 
screens occure [sic] due to disturbances caused by the host machine, or a communication line or 
the like, thereby requiring recovery by an operator." Kanetake et al. '447, column 1, lines 35-38. 
With these problems in mind, the system of Kanetake et al. '447 states that one of its objects is 
"to provide an automatic execution system that is capable of handling an exceptional operation 
without changing or adapting an application program to be automatically executed." Kanetake et 
al. '447, column 2, lines 28-31. To determine if an exceptional screen has occurred, "information 
for specifying the screen (e.g., a screen number or a characteristic message) is recorded, whereby 
it is compared with another at the time of re-execution to confirm that the automatic execution is 
being carried out in accordance with a predetermined procedure." Kanetake et al. '447, column 
3, lines 9-13 (emphasis added). 

Normal information processing "is executed based on a plurality of normal processing 
screen specifying data items that are stored in an ordered sequence." Kanetake et al. '447, 
column 3, lines 24-26. As defined by Kanetake et al. '447, "the expression 'stored in an ordered 
sequence' represents a concept covering not only the case where the involved data items are 
stored in the order of their assigned sequential numbers, but also another case where such data 
items have such information (e.g., address information) that enables access to a next data item." 
Kanetake et al. '447, column 3, lines 59-64. Importantly, "stored in an ordered sequence" does 
not refer at all to any type of textual listing of the display order of the UI screens in a text based 
setup data file. Instead, when Kanetake et al. '447 refers to data screens being "stored in an 
ordered sequence" this means that the data screens themselves are stored in the order of their 
assigned sequential numbers or that the data screens have information (e.g., address information) 
that enables access to a "next" data item. Nowhere does Kanetake et al. '447 state that a listing 
of the display order of all of the data screens exists in any separate text based setup data file that 
may be edited by a text editor. 
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While not described in Kanetake et al. '447, the applicant believes from this description 
that in order to change the order in which the normal processing screens are displayed to the 
user, one would have to actually rearrange where these screen data items are actually stored in 
memory or the address of the screen data items themselves. This is because the system of 
Kanetake et al. '447 generates the screen data items associated with each event by utilizing an 
indexing variable "i" that specifies the data item to the application for causing the application to 
generate the appropriate screen data item. This indexing variable V is then indexed by 1, etc. 
See Kanetake et al. '447, column 3, lines 23-57; column 4, lines 17-59; column 4, lines 60 - 
column 5, line 27; column 5, line 28 - column 6, line 10; column 6, lines 15-47; column 6, line 
48 - column 7, line 16; column 7, line 17 - column 8, line 2; etc. This processing of the 
indexing variable "i" is illustrated in Fig. 12. 

The storage of the screens based upon the indexing variable "i" is confirmed through 
examination of Fig. 10 and the description of this figure at column 23, lines 1-17. In this section, 
and in accordance with the applicant's interpretation of this reference, the normal screens are 
described as "normal screen 'Ai' (l<i<N). M Clearly, the indexing variable "i" is indexed between 
1 and N to select the next screen that is "stored in an ordered sequence". The applicant 
respectfully submits that the use of an indexing variable is inconsistent with the requirement for 
a display order textual listing which does not require that the display screens be stored in an 
ordered sequence, i.e., stored in the order of their assigned sequential numbers or having address 
information that enables access to the next data item through an indexing variable "i". 

While the Examiner is correct that the use of the incrementing variable "i" does not 
disprove the existence of a text based setup data file, the applicant respectfully submits that it is 
the duty of the Examiner to identify the existence of such a text based setup data file in order to 
reject the claims of the instant application as being anticipated, not the contrary. 

Instead of identifying a text based setup data file, the Examiner points to the discussion in 
column 18 describing the registration process, and has concluded that "the registration acts like a 
setup data file." However, the applicant notes with significance that this registration does not 
dictate what screens are actually to be displayed, but instead is merely used to compare with 
another registration generated at the time of re-execution to determine whether normal 
processing or exception processing is taking place. In other words, the registration is not utilized 
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to control the display order of UI screens, but is merely used to determine whether the screen that 
is being displayed is a normal or an exceptional screen resulting from a disturbance caused by 
the host machine or a communication line or the like thereby requiring recovery by an operator. 
As such, this registration cannot be equated with a text based setup data file as used and defined 
in the instant application and claims. It is not appropriate to indicate that any listing of data 
constitutes a text based setup data file as this term is used and defined by the applicant in the 
instant application. Not only is the registration not used as a setup data file dictating the display 
order of screens during an installation process, but Kanetake et al. '447 only uses the registration 
to merely confirm that automatic execution is being carried out in accordance with a 
predetermined procedure by checking the registration with another registration generated as each 
screen stored in the ordered sequence is displayed. 

Additionally, since these registrations are compared to determine whether an exceptional 
screen needs to be displayed, it would not appear to make sense to allow editing of this 
registration as such may well result in erroneous indication that an exceptional procedure has 
occurred. That is, as it appears that the registration is used as a tracking mechanism during the 
display of the screens during automatic execution of the procedure, the allowance of editing of 
the registration may well cause improper processing. This is because the comparison to the 
edited registration may no longer match the registration generated at time of re-execution even 
though no exceptional processing has occurred. 

In view of the foregoing, the applicant respectfully submits that claims 1 -7 are not 
anticipated by Kanetake et al. '447. Reconsideration of this ground of rejection and indication of 
the allowability of claims 1-7 at an early date are respectfully solicited. 

The Examiner has also rejected claims 8-15 under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. Patent No. 6,259,447 to Kanetake et al. and further in view of U.S. Patent 
No. 6,360,365 to Curtis. The applicant has again reconsidered each of these references and the 
Examiner's combination thereof, but must respectfully traverse this ground of rejection. 
Reconsideration of this ground of rejection and indication of the allowability of claims 8-15 in 
view of the following remarks are respectfully solicited. 
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In the applicants previous response, the applicant pointed out that the Examiner had not 
provided any suggestion or motivation to support a prima facie case of obviousness. 
Specifically, the Examiner had merely stated that the motivation to combine these references is 
"because a suite installation is merely a limited example of one of Kanetake automatically 
executing applications." However, such a statement merely indicates that the references are 
within the same field, and does not provide any statement of suggestion or motivation to make 
the proposed combination. Further, MPEP §2143.01 makes clear that the mere fact that the 
references are in the same field and can be combined or modified is not sufficient to support a 
prima facie case of obviousness. 

In response to this argument the Examiner stated "thus both inventions are related to 
making existing applications manageable as computer environments evolve, and thus the 
combination is obvious." However, the applicant respectfully submits that this statement is once 
again merely stating that the references are in the same field and therefore their combination is 
obvious. However, such a conclusory statement does not satisfy the requirements of the MPEP 
to establish a prima facie case of obviousness. Indeed, the Federal Circuit has made clear that 
such conclusory statements are not sufficient to establish a prima facie case of obviousness. See 
In Re Lee, 277 F.3d 1338, 1342-44, 61 USPQ2d 1430, 1433-34 (Fed. Cir. 2002). 

Obviousness can only be established by combining or modifying the teachings of the 
prior art to produce the claimed invention where there is some teaching, suggestion, or 
motivation to do so found either explicitly or implicitly in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art. "The test for an implicit 
showing is what the combined teachings, knowledge of one of ordinary skill in the art, and the 
nature of the problem to be solved as a whole would have suggested to one of ordinary skill in 
the art." In Re Kotzab, 217 F.3d 1365, 1370, 55 USPQ2d 1313, 1317 (Fed. Cir. 2000). Indeed, 
the Federal Circuit has recently confirmed the importance of relying on objective evidence in 
making specific factual findings with respect to the motivation to combine references, none of 
which has been done in this case. See In Re Lee, 277 F.3d 1338, 1342-44, 61 USPQ2d 1430, 
1433-34 (Fed. Cir. 2002). 
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In view of the above, the applicant respectfully submits that the Examiner has failed to 
establish a prima facie case of obviousness because there has been no sufficient statement of the 
suggestion or motivation to make the proposed combination. 

Further, a prima facie case of obviousness has also not been established because the 
references as combined do not meet each and every limitation of the claims. Specifically, and as 
discussed at length above, the Kanetake et al. '447 patent does not teach or suggest a text based 
setup data file that includes a display order textual listing. Instead, the Examiner relies on the 
registration information which the Examiner states "acts like a setup data file." However, this 
registration information in fact does not act like a setup data file because such a setup data file is 
used by the suite installation toolkit to govern the operation of the installation of the suite and, in 
particular, the order in which user interface screens will be displayed during the installation 
process. This functionality is completely foreign to the registration information, which is used to 
compare with registration information recorded as screens are displayed during the processing of 
an application to determine whether an exception has occurred. This deficiency is not cured by 
the combination of Curtis '365. As such, the applicant respectfully submits that a prima facie 
case of obviousness has not been established for this additional reason as well. 



In view of the above the applicant respectfully submits that claims 1-15 are in condition 
for allowance. Reconsideration of claims 1-15 and indication of their allowability at an early 
date in view of the foregoing remarks is respectfully solicited. 



If the Examiner believes that a telephonic conversation will aid in the resolution of any 
issues not resolved herein, the Examiner is invited to contact the applicant's <j#dj&ey at the 
telephone number listed below. 




Date: September 24, 2004 



leg. No. 37390 
)IT & MAYER, LTD. 
Road, Suite 300 
llinois 61114-8018 
5-7661 (telephone) 
(815) 963-7664 (facsimile) 
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